1. Technical Field
This disclosure relates generally to application security and, in particular, to a method to enable the passing or obtaining of a credential for a “rich client” from within an existing web browser session.
2. Background of the Related Art
It is known in the prior art to integrate Web- or cloud-based applications with so-called “rich” clients, where a “rich” client is a client (of a client-server application) that supports its own interface (as opposed to merely exporting the web interface from the web application itself). A “rich” client typically is not browser-based, and it is sometimes referred to as a “thick” (as compared to a browser-based or “thin”) client. An illustrative rich client is Lotus Notes®, which provides email, calendaring, contact management, and instant messaging. A rich client can be used to access and automatically perform actions on behalf of a user.
Many non-browser-based (rich) client applications of this type also have browser-based (thin client) application counterparts or features. The thin client may be a simple web browser and a login page. When an end-user wants to use these multiple clients at the same time from a single workstation, he or she must authenticate separately to an authorization server. A common approach to this requirement is to use a password that is then entered in multiple interfaces, e.g., one for each client. This approach is not user-friendly, as the user needs to enter his or her password multiple times. Moreover, where the user stores the password locally (in each client), it increases the risk of compromise given that multiple copies are stored. Further, when the user changes the password, it likewise must be changed in multiple places. Of course, when a user is forced to enter a password multiple times, it is more likely than not that the user will select a weak one. Another problem arises if the Web- or cloud-based application uses a single sign-on protocol (such as SAML or OpenID) that does not support password-based authentication that is typical for the thin client approach. In such case, the user is then forced to use distinct types of authentication credentials and techniques for each of the thick and thin clients, creating further inefficiencies and security risks.
It would be desirable to be able to provide a technique by which a user need only authenticate once during a session with a Web- or cloud-based application, but wherein this authentication can be propagated, or otherwise made available, to an associated rich client that can be discovered by the user.